Work Request Manager API

2.1.x
(1 review)

About the WRM API

Overview

The Work Request Manager (WRM) API enables Chorus (the Work Requestor) and Services Companies (Work Suppliers) to have consistent, comprehensive, and structured communications when dealing with work requests, over the one channel, and across all work types.

Work requests include detailed information about the site, contacts, assets, and inventory. The API can be used to provide or receive additional information relevant to the work being performed. See API Resources > Event notifications and Receiving notifications.

Work Request Structure

A work request is consists of a single parent task and one or more child activities. A task is only ever allocated to one Work Supplier.

The Work Requestor (Chorus) is responsible for managing the task and the Work Supplier manages the activity(s). The task lifecycle is related to, but independent of the activity lifecycle.

Data Model

The data model holds all the structured data that comprise a work request. The diagram below describes the WRM data model and shows the relationships between the different entities.

resources/Anypoint%20Data%20Model%20Diagram-589c3871-9d8d-427a-9735-9957b8872c88.jpg

Data Model Objects

This table describes the main objects in the WRM data model.

Object Description
Task

A Task:

  • is the parent entity in the Work Request hierarchy
  • is controlled by the Work Requestor (Chorus)
  • can be allocated to only one Work Supplier
  • includes one or more child activities
  • has a lifecycle independent of the activity.
Activities

An Activity:

  • sits under the task in the Work Request hierarchy
  • is controlled by the Work Supplier (Service Company)
  • has only one parent activity
  • has a lifecycle independent of the task.
Source

The Source:

  • is included as part of the Task information
  • contains all information about the specific piece of work based on the data source, (Fibre Connect, Incident and Maintenance).
Schedule

The Schedule:

  • sits under the activity
  • is used for scheduling work
  • is used for scheduling and rescheduling end customer appointments
  • can be updated by either the Work Supplier or the Work Requestor.
Site

The Site:

  • sits under the activity
  • has a one-one relationship with a Work Request
  • includes, Details about the location, address, and co-ordinates
  • within the site object, the only details that can be updated are the access instructions and site contacts.
Contact

Contacts:

  • appear in mutliple places within the task structure, e.g. the worker assigned to an activity, or a contact at the site
  • all contact objects have the same structure
  • site contact and worker contacts may be updated by the Work Supplier.
Data Types

This table describes the different data types used in the WRM API.

Data Type Detail
Date / Time (datetime)

All Chorus APIs use UTC time in ISO 8601 format, with or without decimal fraction seconds, i.e.:

  • yyyy-MM-ddTHH:mm:ssZ (e.g. 2016-02-29T19:20:30Z), or
  • yyyy-MM-ddTHH:mm:ss.SSSZ (e.g. 2016-02-29T19:20:30.089Z)

Where:

  • yyyy: four-digit year
  • MM: two-digit month (01=January, etc.)
  • dd: two-digit day of month (01 through 31)
  • T: literal string to delimit date and time components
  • HH: two digits of hour (00 through 23) (do not use am/pm)
  • mm: two digits of minute (00 through 59)
  • ss: two digits of second (00 through 59)
  • SSS: three-digit decimal fraction of a second, optional (must be three digits if used)
  • Z: time zone designator, Z for UTC time
Boolean For each Boolean attribute Chorus has set the default value that can be overwritten.
Strings Most of our strings have no character limit except for some of our notes and additional information fields that have a 5000 character limit.
Arrays Where an object is configured as an array of name / value pairs the content isn't validated in the WRM. This means you may receive a 200-success notification from the WRM even if the content is invalid. Examples of arrays are the outcomes array (as part of the UpdateTaskActivityOutcomesEvent event notifiation) and the additionalInfoDetail array (as part of the UpdateTaskAdditionalInfosEvent event notification) sent by the Work Supplier, and the assets array (as part of the UpdateTaskAssetsEvent event notification) sent by the Work Requestor.
Enumerations (enums) The WRM contains many enumerated lists, some that are validated.
Events and Notifications

The Work Request Manager includes a suite of events and notifications to provide communication and status updates between the Work Requestor and Work Supplier. Events and notifications are how a work request moves through the end-to-end process. See How to use the WRM API.

A Work Requestor or Work Supplier sends an event to the WRM and the WRM routes the information as a notification to the required recipients. For each event there is a corresponding notification.

The diagram below shows how the WRM receives events and sends notifications.

resources/WRM%20Events%20Diagram-02300020-6821-45c7-8b93-e3b8d10f8c43.jpg

Reviews